One of the more important requirements of a digital communication network is to support real-time communications applications which, typically, require time or frequency alignment, or a combination of both. For example, time alignment is used by real-time instrumentation systems gathering data at specific time intervals or operating machinery according to specific timing. Frequency alignment is required in time-division-multiplexed (TDM) systems and in multi-media streaming systems, which require fixed, reproducible, video or audio sample rates across multiple clients.
While frequency alignment within conventional TDM networks is relatively straightforward, packet-switched networks, such as networks based on Internet Protocols (“IP”), present time and frequency alignment challenges because packet networks are not conventionally designed to provide precise delivery time for data or precise timing. A key difference is that the switching and multiplexing functions are not deterministic, as they are in TDM networks, but have a random aspect as well. In particular, packet networks typically involve multiple nodes that may store and forward data packets, potentially introducing significant, randomly distributed, transit delay variation between any two points.
To address time and frequency alignment challenges inherent in packet networks, certain protocols based on the industry standard internet protocol (IP) have been developed and deployed. One IP-based time alignment protocol is known as the Network Time Protocol (NTP). NTP is used for aligning time between a client and one or more master time references. Precision Time Protocol (PTP) is a second IP-based time alignment protocol for aligning one or more client devices to a master time reference. Both NTP and PTP provide for the use of syntonized time-stamp clocks (i.e, they are aligned in frequency) in master (sending) devices and slave (receiving) devices to produce time-stamps for achieving this alignment of time references. Master devices can be any of a variety of devices (e.g., communication sources, servers, etc.) that are sending packets to slave devices, which in turn can be any of a variety of devices that are receiving packets (e.g., communication destinations, clients, etc.).
FIG. 1 (Prior Art) is a conceptual deployment diagram that illustrates a slave clock in a slave device (destination/slave/client) 102 synchronizing to a master clock in a master device (source/master/server) 101 over a packet network 103. The packet timing signals 104 communicated over the packet network 103 include time-stamped packets exchanged between the master and slave devices at a nominally regular interval with, for example, T0 time units (e.g., seconds) between packets. In FIG. 1 (Prior Art), the transit delay from the master device (source/master/server) 101 to the slave device (destination/slave/client) 102 is represented by the ΔMS arrow 108. And the transit delay from the slave device (destination/slave/client) 102 to the master device (source/master/server) 101 is represented by the ΔSM arrow 109. The slave device (destination/slave/client) 102 uses time-stamps associated with the packet timing signals 104 to generate local clock signals represented by clock output 105.
The nature of the timing signals is provided in FIG. 2 (Prior Art). The timing packet that traverses the network from master to slave leaves the master 210 at time t1 (labeled as “A”). This constitutes the time-of-departure time-stamp. After a transit delay of ΔMS 240, the packet arrives at the slave 220 at time t2 (labeled as “B”). The slave measures this time-of-arrival as τ2 based on the slave clock. In other words, the time-stamp for time-of-arrival has the value τ2. Denoting by ε the time offset of the slave clock relative to the master clock, the time t2 for the time-of-arrival at the slave 220 can be represented by the following equation:t2=τ2+ε  (Eq. 1)
For packets originating at the slave 220 and transmitted to the master 210, the time-of-departure time-stamp contains τ3, which represents the slave-clock estimate of time-of-departure. The actual (based on the master timescale) time-of-departure t3 (labeled as “C”) is related to τ3 by the following equation:t3=τ3+ε  (Eq. 2)
The transit delay across the network is ΔSM 244. Thus, after a transit delay of ΔSM 244, the packet arrives at the master 210 at time t4 (labeled as “D”).
Such a two-way exchange of packets can provide information suitable for allowing the slave to align in time with the master (assuming that both sides have knowledge of the time stamps). There are four measured values (time-stamps) that can be communicated between the Master and Slave, namely, timestamps associated with t1, τ2, τ3, and t4, which are described with respect to FIG. 2 (Prior Art). It is noted that this two-way exchange involves one packet (message) in each direction, and these messages do not necessarily have to be consecutive as long as the time-stamp information is communicated appropriately. In some instances, the rate at which packets are transmitted in the two directions can be different.
Denoting as ΔMS and ΔSM the transit delays between the Master-to-Slave communication and Slave-to-Master communication, respectively, the following equations can be established:t4=τ3+ε+ΔSM(from a S-to-M packet)t1=τ2+ε−ΔMS(from a M-to-S packet)  (Eq. 3)
In this actual time-transfer situation, there are two equations with three unknowns. As such, it is common practice to assume reciprocity of transit delay between the two devices (i.e., assuming that ΔMS equals ΔSM), thereby reducing the number of unknowns to two. Making this assumption and computing for ε, this slave wall-clock time offset-from-master (“ofm”) value ε can be indicated as follows:
                    ɛ        =                                                            (                                                      t                    4                                    +                                      t                    1                                                  )                            -                              (                                                      τ                    3                                    +                                      τ                    2                                                  )                                      2                    =                                                    (                                                      t                    4                                    -                                      τ                    3                                                  )                            -                              (                                                      τ                    2                                    -                                      t                    1                                                  )                                      2                                              (                  Eq          .                                          ⁢          4                )            
There are several phenomena that interfere with the accuracy and precision whereby the slave clock can determine its time offset-from-master. One such error contribution is related to the basic nature of packet-switched networks whereby the transit delay of packets from source to destination can vary from packet to packet. This effect, also called packet delay variation (PDV), restricts the ability of the slave to align with the master perfectly. Further, because the oscillator in the slave clock is not ideal, it could drift between packet transmissions, and the assumption that the slave time clock offset-from-master (ε) is “constant” over the interval of packet exchange is not exact. Several methods and techniques have been disclosed to address these kinds of error sources and mitigate their impact on the performance of the clock. These methods commonly apply low-pass filtering. That is, the noise type is random, and by applying suitable filtering methods, the noise power is reduced, improving the signal-to-noise ratio.
It is noted that for very high precision/accuracy time-transfer in packet networks, there are no intervening devices between the Master and the Slave. In PTP architectures, this lack of intervening devices is referred to as the networking providing “on-path support,” and each intervening device between the end-point clocks is called a “boundary clock.” In effect, each boundary clock is a slave clock on one side (e.g., the “upstream” or “Master” side) and a master clock on the other side (e.g., the “downstream” or “Slave” side). In this situation, the transit delay of packets from master/source to slave/destination is nominally constant.
One other source of error that has not been addressed previously is the error in the time-stamp value itself. If the time-stamp function provides an erroneous value for the time-of-departure or the time-of-arrival of a packet, then this error propagates into the estimate of the slave clock time offset-from-master. As described below with respect to FIG. 3A (Prior Art) and FIG. 3B (Prior Art), prior methods for generating time-stamps can introduce a time-stamp error that is static and, therefore, cannot be filtered out by traditional means. In boundary clock scenarios, this source of error is one of the primary contributors to the error in typical time transfer systems.
FIG. 3A (Prior Art) is a block diagram of an embodiment 300 for circuitry that generates a time-stamp for network packets. For this embodiment 300, a nominal packet rate is considered to be f0, and the nominal packet interval is considered to be T0, such that f0=1/T0. As shown in FIG. 3A (Prior Art), the time-stamp clock 306 (e.g., clock rate=fTS) runs a counter 302. Transitions in the least-significant bit are associated with a time-equivalency of ΔTS=1/fTS. (In some implementations, the increment is other than unity, allowing a different weight (in time units) than ΔTS=1/fTS.) Thus, the effective granularity of the time-stamp is ΔTS.
For the embodiment 300 depicted, the event to be time-stamped (e.g., receipt of a packet from the network for time-of-arrival) generates a load-pulse 308 based upon an event trigger. This load-pulse 308 causes the counter 302 to be sampled to generate a time-stamp value, and this time-stamp value 303 is stored in the time-stamp register 304, which can output a time-stamp of the last event, if desired, or can be accessed in some other desired manner. The event time-stamps 305 can then be received and used in a slave device (Slave), for example, in synchronizing its operations to a clock from a master device (Master) on the network.
It is noted that it is incorrect to assume that the time-of-arrival of a packet is necessarily aligned to an edge of the time-stamp clock (fTS). Consider the case of time-stamp T2 representing the Slave's estimate of the time-of-arrival of a packet sent by the Master, as discussed in more detail with respect to FIG. 3B (Prior Art) below. The Slave's time-stamp mechanism does not influence what time the Master sends the packet, and also the Slave does not have any control over the transit delay of the packet over the medium. In the Slave, the signal processing, for example, associated with demodulation of the signal, clock-and-data recovery, and/or determination of the appropriate bit rate, initiates a strike of a slave time-stamp based upon an event, such as the load pulse 308 in FIG. 3A (Prior Art). The Slave time-stamp clock edge used to generate the time-stamp is likely not to align exactly with the actual time of receipt of the packet.
Thus, all events that occur between n●ΔTS and (n+1)●ΔTS will map into the same time-stamp value for the Slave device. This ability to generate time-stamps for events only at the precision of the time-stamp clock is the notion of quantization or granularity of the time-stamp. Put another way, there is an uncertainty of ΔTS associated with a time-stamp as compared to the actual time of the event in continuous time.
In practice, time-stamps are taken in pairs. Specifically, the time offset-from-master (ofm) as computed by the Slave is given by the following equation:
                              ofm          ⁡                      (            n            )                          =                                            (                                                                    T                    4                                    ⁡                                      (                    n                    )                                                  +                                                      T                    1                                    ⁡                                      (                    n                    )                                                              )                        -                          (                                                                    T                    3                                    ⁡                                      (                    n                    )                                                  +                                                      T                    2                                    ⁡                                      (                    n                    )                                                              )                                2                                    (                  Eq          .                                          ⁢          5                )            where T4(n) and T1(n) are the time-of-arrival and time-of-departure time-stamps struck at the Master and T2(n) and T3(n) are the time-of-arrival and time-of-departure time-stamps struck at the Slave. The index (n) represents the notion of the ofm being calculated using the nth packet exchange.
The primary reason for associating the time-stamps as shown in Equation 5 above is to recognize that T1 and T4 are “Master” time-stamps (generically designated in the figures as TSM) and T2 and T3 are “Slave” time-stamps (generically designated in the figures as TSS). Consequently T1 and T4 are struck at the same port and, likewise, T2 and T3 are struck at the same port. On the slave side, the time-stamp granularity noise can be written asεTS(S)(n)=−½●(ε3(n)+ε2(n))  (Eq. 6)where ε3(n) and ε2(n) are the time-stamp granularity noise contributions for time-stamps T3(n) and T2(n), respectively. The negative sign is solely for convenience. When considering errors, the more relevant metrics are related to power, and for power, the sign is moot. Likewise, on the Master side, the time-stamp granularity noise can be written asεTS(M)(n)=½●(ε4(n)+ε1(n))  (Eq. 7)where ε4(n) and ε1(n) are the time-stamp granularity noise contributions for time-stamps T4(n) and T1(n), respectively.
FIG. 3B (Prior Art) is a timing diagram of an embodiment 350 for communication of a packet involving a Master time-stamp 356 and a Slave time-stamp 358. For prior solutions, the clock rate for the Master time-stamp clock 354 is the same as the clock rate for the Slave time-stamp clock 352. The time-of-departure 360 represents when the packet is transmitted by the Master and first time-stamp (T1) 356 represents the Master time-stamp. The time-of-arrival 364 represents when the packet is received by the Slave, and the flight time 362 represents the time the packet takes to travel from Master to Slave. The second time-stamp (T2) 358 represents the time-stamp struck at the Slave for the transmitted packet. The difference between the clock edge representing this time-stamp (T2) 358 and the actual time-of-arrival 364 is represented as time difference (Δ) 370.
Considering this case where a time-stamped packet is transmitted from the Master to the Slave, the time-of-departure 360 is assumed to be aligned with an edge of the time-stamp clock in the master, although it could be misaligned in practice. However, this misalignment is static in nature. The packet is delivered over the medium, for example, at 1 Gbit/s Ethernet, and arrives at the Slave (receiver) where the time-of-arrival is established. For a given situation, the flight time 362 over the medium can be considered essentially constant from packet to packet.
In legacy and conventional network communication systems, the time-stamp clock 352 in the Slave (receiving device) is implemented using the same nominal rate as that of the time-stamp clock 354 for the Master (sending device). A typical value for the clock rate for 1 Gbit/s Ethernet, for example, is 125 MHz, corresponding to a time-stamp time granularity of 8 ns.
As depicted in FIG. 3B (Prior Art) a time-stamped packet leaves the Master (time-stamp=T1) and it leaves on the rising edge of the time-stamp clock 354. The time-stamp 356 has no granularity error associated with it because of the assumption that the time-of-departure 360 is aligned with an edge of the time-stamp clock 354.
The packet arrives at the Slave (receiver) after some time represented by the flight time 362. At the Slave (receiver), there is some granularity error because there is no guarantee that the time-of-arrival 364 will be in alignment with an edge of the time-stamp clock 352. As depicted in embodiment 350, the time-stamp associated with time-of-arrival 364 will be the value of the clock at the closest edge prior to the time-of-arrival. This is designated as slave time-stamp (T2) 358. The time-stamp granularity error is Δ or the difference 370 between the clock edge for time-stamp clock 352 and the actual time of arrival 364.
Three cases can be considered for different aspects of errors associated with the time-stamp by the Slave (receiver).
First is a case where the slave clock 352 is syntonized with the master clock 356 (i.e., they are aligned in frequency). In this case, the rates of the time-stamp clocks nominally will be the same, and as a consequence, the phase difference between the two clock waveforms shown in FIG. 3B (Prior Art) will be a constant if the two clocks have the same nominal rate (in Hz). Because the flight time 362 can be assumed to be the same for each packet, it follows that the time-stamp granularity error (Δ) 370 will be the same for each packet. Such a systematic granularity error is impossible to filter out in subsequent processing. This effect is sometimes referred to as the “beating effect.” The slave time-clock will thus be different from the master time-clock because of this systematic phenomenon, and the error will be some value between 0 and ΔTS where ΔTS is the period of the time-stamp clock (e.g., 0-8 ns for a 125 MHz clock).
Next is a case where the slave clock is almost syntonized with the master clock (i.e., they are almost aligned in frequency and the offset is small and almost constant and the nominal rate of the time-stamping clocks is the same). In this case, the frequency, and therefore the rate, of the time-stamp clocks 352 and 354 will be the almost same. As a consequence, the phase difference between the two clock waveforms will be almost the same and will change slowly over time. Because the flight time 362 is again assumed to be the same for each packet, it follows that the time-stamp granularity error (Δ) 370 will almost be the same for each packet. Such a low-frequency error is hard to filter out, for example, using a low-pass filter. The slave time-clock will thus be different from the master time-clock because of this phenomenon, and the error will be some value between 0 and ΔTS where ΔTS is the period of the time-stamp clock (e.g., 0-8 ns for a 125 MHz clock), and this error will change slowly over time.
Third is a case where the slave clock is not syntonized with the master clock (i.e., they are not aligned in frequency). For this case, even if the nominal rate of the time-stamp clocks is the same, they will drift with respect to each other. As a consequence the phase difference between the two clock waveforms shown in FIG. 3B (Prior Art) will not be a constant. Because the flight time 362 is the same for each packet, it follows that the time-stamp granularity error (Δ) 370 will not be the same for each packet and will be have high Fourier frequency content. Such a high frequency error is possible to filter out, for example, using low-pass filter techniques. However, this situation will likely occur only during start-up and reset of the Slave/Master devices. In steady-state operation, the Slave is synchronized to the Master, and this implies that the slave clock and master clock will almost be the same frequency, and this operation will therefore reduce to either the first or second case described above.
These cases will occur, for example, between Master and Slave communications for Gigabit/sec Ethernet communications where the MII (media independent interface) clock rate (e.g., 125 MHz) is used by both the Master and Slave devices to generate time-stamps for network synchronization.
Prior systems and techniques do not provide the ability to handle these cases where small systematic granularity errors exist with respect to Master and Slave time-stamp clocks that are operating at the same nominal rate, such as the MII (media independent interface) clock rate (e.g., 125 MHz) for Gigabit/sec Ethernet communications.